CDRL  01000 
TASK  BR24 


The  BOEING  Company 
D6 13- 11 GOO 


CDRL  01000 


AD-A240  474 


Software  Technology  for  Adaptable, 
Reliable  Systems  (STARS) 


Submitted  to: 

Electronic  Systems  Division: 

Air  Force  Systems  Command,  USAF: 
Hanscom  AFB,  MA  01731-5000: 


OTIC 

ELEGTE 
SEPll  1991 

c 


Contract  No: 
F19628-88-D-0028 


CDRL  1000 
BR24  Final  Report 


July  1,  1990 


The  Boeing  Company 
Space  and  Defense  Group 
Boeing  Aerospace  and  Electronics 
P.O.  Box  3999 
Seattle,  Washington  98124 


/^proved  for  public  release  -  distribution  is  unlimited^ 


BR24  Final  Report 


1 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMBNo.m04-0188 


rusiic  topcar^  Dtf  M*v  ns  caiocdoo  o:  normitc^  is  estmaiK  to  «v*ra^  i  nor  p«  tnponM.irtcfeJcv);  r»  tme  tof  rtvitwAn}  insiucoons.  SM.'er»n9  •215)09  cau  9«rMrtn9  anc  tnanannc  nt  oaa  n«»Me.  too 

co'n^atn:  v\i  toe  coCecIcn  oiioforma^on.  Send  ccmments  teQardng  this  burdih  estmale  0(  any  othe*  aspect  ol  hs  c^ectsn  ol  ntofmaton.  ndJdn;  su9gesbcm  lor  redu9n9  tis  burden,  to  WasSn^ton  Keadpoarle's 
Services,  b^ectcrate  ior  htorma^  Operatons  and  Reports.  1215  Jeliersorv  Davis  Higtway.  Sale  1204.  Arir^tcn.  VA  22202-4^2,  and  to  the  Offce_^  Manage.nent  ar»o  Budget  PaperwcrK  Reducton  Ptqecl  {C7(K^t  &S,.  Washington, 
nr 


1  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 


S.FUN0NG  NUMBERS 

C:  F19628-88-D-0028 


.AGENCY  USE  ONLY  Utnk) 

N  REPORT  DATE 

Ol-JUL-90 

..TniEAND  SUBTITLE 


BR24;  Final  Report 


.  6  AUT.HORIS) 

David  H.  Jones 


TA:  BR-24 


7,  PERFORMING  0RGAN)7AT10NNAME(S)  AND  AODRESS(ES) 

The  Boeing  Company 
Boeing  Aerospace  and  Electronics  Division 
Systems  and  Software  Engineering 
P.O.  Box  3999 

Seattle,  Washington  98124 

t.  SPONSORNG/MOICTORING  AGENCY  NAME(S)  AND  A0DRESS|ES) 

‘  ESD/AVS 
Bldg.  17-04 
Room  113 

.  Hanscom  Air  Force  Base,  01731-5000 


a  PERFORMING  ORGANZATION 
REPORT  NUMBER 


D-613-  11000 


ID.  SPONSORING  /MONITORING 
AGENCY  REPORT  NUMBER 


1).  SUPPLEMENTARY  NOTES 


|t2L  DISTRIBUTION/AVAILABILnY  STATEMETPr 


Itsa  DISTRIBUTION  CODE 


Approved  for  public  release  -  distribution  unlimited. 


13.  ABSTRACT  (Uiximum  200  wvdi) 


Several  people  in  the  STARS  program  working  in  the  area  of  user  interface  technology 
have  indirectly  contributed  to  the  work  presented  here:  Mark  Nelson  of  SAIC  and 
Kurt  Wallnau  of  Unisys .  Bob  Rosen  of  Boeing  was  the  principle  contributor  to  the 
implementation  scheme  used  in  the  prototype.  The  Boeing  Commercial  Airplane  Group's 
Avionics  Flight  Systems  Central  Software  also  contributed  the  Ada  binding  to  Motif 
that  was  developed  by  their  group. 


Ik.  SUBJECT  TERMS 


Keywords:  stars 

virtual  interface 
X  Windows  System 


INSECURITY  CLASSinCATIDN 
OF  REPORT 

Unclassified 
NSN  7540-01-280-5500 


IB.  SECURITY  CLASSIRCATIDN 
OFTHISPAGE 

Unclassified 


user  interface 

user  interaction  tasks 


18,  SECURITY  CLASSIHCATION 
OF  ABSTRACT 


Unclassified 


IS.  NUMBER  OF  PAGES 

44 

16.  PRICE  CODE 

20.  LIHilATlOK  Or  ABSTRACT 

None 

Standard  Form  298  (Rev.  2-89) 

Prescrib«U  by  ANSI  StU  23S-1B 
23S-102 


I 


CDRL  01000 
TASK  BR24 


The  BOEING  Company 
D613-11(K)0 


CDRL  01000 


Prepared  by 


Reviewed  by 


Reviewed  by 


Approved  by 


Name  of  CDRL 


STARS  Program  Manager 


BR24  J'inal  Report 
D6 13-1 1000 


CDRL  01000  The  BOEING  Company  CDRL  01000 

TASK  BR24 
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I’his  document  reports  the  results  of  the  Boeing  STARS  task  BR24,  User  Meta 
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based  on  the  prototype  sample  application.  'I’here  is  a  technical  discussion  of  the 
implementation  of  SUITE;  recommendations  for  future  work  are  identified. 
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1.  SCOPE 

This  documcnl  summarizes  and  reports  on  the  work  carried  out  under  the  Btreing 
STARS  task  J5R24,  User  Meta  Interface  (henceforth  called  the  STARS  User  Interface 
Toolkit  (SUITli)).  'I’he  contents  include  BR24  results,  a  technical  discussion  of  the 
sum-  implementation,  and  recommendations  for  future  work. 

2.  REFERENCED  DOCUMENTS 

'I  his  section  lists  all  documents  referenced  in  this  1-inal  Report. 

(B1*'R89|  Berard,  E.  Creating  Reusable  Ada  Software,  EVB 'IVaining  (!ourse,  1989 

(150087 J  Booch,  G.  Software  Components  With  Ada,  Benjamin-(!ummings,  1987 

(C1)RL98()1  Programmer's  Guide  for  STARS  User  Interface  Toolkit  (SUITE).  Jan  31, 
1990.  Boeing  STARS  (!DRL  #  980,  Electronic  Sy.stems  Division,  Ilan.scom  Al-B. 

|(!DRI,9701  Ada  Code  .for  Meta  Level  Interface,  July  1,  1990.  Boeing  STARS  (!DRL 
#  970,  fdectronic  Systems  Division,  Hanscom  AEB. 

|(!DRL990|  Ada  (’ode  for  Prototype  Sample  Application,  July  1,  1990.  Boeing 
STARS  CDRL  #  990,  Electronic  Systems  Division,  Hanscom  Al-B. 

(Foley  84(  I-oley,  J.D.,  et.  al..  "The  Human  Factors  of  Computer  Graphics  Interaction 
Techniques",  IHliE  C’omputer  Graphics  and  Applications  4(1 1):13-48,  Nov.  1984. 

(P1-'R87(  Perez- Perez,  H.  Simulating  Inheritance  with  Ada,  Ada  Letters,  Sept.  1987 

(WAL90(  Wallnau,  K.  Ada/Xt  Architecture:  Design  Report,  January  1990.  STARS 
CDRL  #01000,  Electronic  Systems  Division,  Hanscom  Al-'B. 

3.  NOTES 

'I'his  section  contains  information  only  and  is  not  contractually  binding. 

3.1  Abbreviations  and  Acronyms 

API-’ AT  Ada  Program  I-'low  Analysis  Tool 

API  Application  Programmer's  Interface 

SUI  TE  STARS  U.ser  Interface 'Toolkit 

X  X  Windows  System 
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4.  BR24  RESULTS 

4.1  Description  of  the  Prototype  Sample  Application 

'1‘he  sample  application  selected  for  prototyping  was  tlie  Ada  Program  I-low  Analysis 
Tool  (API-A'P),  developed  by  Boeing  in  the  Q  phase  of  the  current  S'FARS  contract. 
APP'AT  was  chosen  to  demonstrate  the  SUi  rii  virtual  interface  because  it  has  a 
variety  of  static  analysis  features  which  produce  information  that  can  be  displayed  in  a 
variety  of  textual,  semi-graphic  modes;  it  can  be  run  in  either  batch  or  interactive 
mode  and  has  a  moderate  degree  of  complexity. 

In  preparation  for  prototyping,  API'A'l*  version  5  was  analyzed  to  determine  what 
modifications  would  be  necessary.  In  addition,  the  unreleased  document  ".Software 
User's  Manual  for  the  Ada  Program  Mow  Analysis  Tck)!"  was  reviewed,  which 
documents  an  object-oriented  user  interface  that  differs  from  the  interface  of  API-A'P 
V5.  Analysis  of  the  two  interfaces  reveals  that  the  interface  de.scribed  in  the  "Software 
U.ser's  Manual"  is  much  closer  to  the  .style  of  interface  supported  by  SUITE,  in 
particular; 

•  It  has  an  object  -  action  .selection  model. 

•  'I'he  structure  is  more  adapted  to  a  user-controlled  dialog. 

•  'I  he  command  structure  reflects  a  richer  and  more  highly  interactive  functionality 
(but  a  functionality  as  yet  not  implemented  in  API-A'F  V5). 


As  a  result  of  this  analysis,  we  decided  to  ba.se  the  user  interface  on  the  "Software 
U.ser's  Manual  for  the  Ada  Program  Plow  Analy.sis '1  ool  (API’A'l')."  An  initial,  brief 
sketch  of  the  new  user  interface  was  written  and  is  summarized  below: 


'I'he  API'AT  user  interface  will  allow  the  user  to  identify  I)  particular  Ada  program 
objects,  2)  information  about  that  object  that  will  be  extracted  from  the  .symbol  table, 
and  3)  display  parameters.  APP’AT  operate.s  on  t)bjects  stored  in  it.s  symbol  table.  'I'he 
types  of  objects  that  will  be  analyzed/di.splaycd  include:  Identifiers,  Task,  Subprogram, 
Package  ,  Pile,  l^xception,  Interface,  and  I'ile.  The  main  application  panel  has 
standard  file  and  help  menus,  plus  menus  to  select  the  Ada  entities,  identifier,  and 
attributes  that  should  be  extracted  from  the  .symbol  tabic  and  displayed.  'I'he  Ada  entity 
to  be  analyzed  is  .selected  from  a  single  choice  list.  The  Ada  program  objects 
(identifiers)  for  which  informativm  is  to  be  extracted  frt>m  the  .syinb«)l  table  arc  .selected 
from  a  multi-choice  text  .selection  list.  A  multi  choice  list  «)f  toggle  items  is  u.sed  to 
.select  the  information  to  be  displayed  about  each  selected  identifier.  'I'he  third 
selection  li.st  (not  implemented)  is  a  multi -choice  list  allowing  the  user  to  di.splay 
information  on  declared  objects.  'I’he  "apply"  button  causes  information  about  the 
selected  object  to  be  extracted  fnrm  the  .symbol  tabic  and  the  output  U)  the  viewport. 
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4.2  Status  of  Work 


In  order  to  dcmonslralc  the  feasibility  of  the  concept  embexlied  by  SUI'I'M,  a  prototype 
sample  application  was  done.  'i\)  support  this  prototype,  portions  of  SUFfli  were 
al.so  implemented.  Only  those  portions  of  SUriTi  that  were  expected  to  be  directly 
u.sed  by  the  sample  application  were  actually  implemented.  As  it  turned  out,  this 
reprc.sentecl  a  large  percentage  of  the  predefined  SUITE  components:  'fhe  only 
components  not  used  by  APl-A'I'  are  valuators  (SUTFE  components  that  permit  the 
user  to  view/enter  a  value  within  a  range  of  value.s),  several  of  the  dialog  panels,  text 
components,  viewport,  and  command  line  interface  panel. 

4.2.1  Implementation  of  SUITE  Components 


'Fhe  implementation  of  SUFFi-'  is  a  hierarchy  of  derived  types  and  a  number  of 
support  packages.  'Fhe  base  types,  from  which  all  other  types  are  derived  are 
completely  implemented,  with  the  exception  of  re.source  management.  (Re.sourcc 
management  implement.s  user  preferences  in  an  implementation  independent  way.) 


'Fhe  following  comp«)nents  arc  implemented  to  a  full  enough  extent  to  support  the 
prototype  sample  application:  Command  Items,  'Foggle  Items,  Menu  Command  Items, 
('ommand  Lists,  Multi-Choice  l.i.sts,  Application  Panel.s,  Applications,  I'ile  .Selection 
Dialogs. 


'Fhe  following  components  are  NOT  implemented  to  a  full  enough  extent  U)  support  the 
prototype  sample  application: 


•  Dialog  Panels  -  Not  tested  with  l-Vames  in.sertcd  in  them. 

•  Frames  -  (!annoi  insert  components  in  the  frame. 

•  'Fext  Selection  -  'Fhis  component  was  not  part  of  the  original  spccificali»>n.  It  is 
needed  U)  support  the  .selection  of  Ada  identifiers  for  which  entries  cxi.st  in 
APl’AT's  .symbol  table.  .See  .section  6  of  the  pre.sent  document  for  a  more 
complete  discu.ssion  of  the  ".Selection  Interaction  'Fa.sk". 

•  'Fext  Display  -  'Fhis  was  also  a  component  that  was  not  part  of  the  tiriginal 
specification.  Its  purpo.se  is  to  support  the  porting  of  existing  applications  that 
u.se  'Fext_l()  by  minimizing  the  number  of  code  changes  necessary  to  u.sc  SUFFL. 
'Fhe  text  display  component  simulates  portions  t>f  the  .standard  package  Tcxt_l(), 
causing  output  to  be  displayed  in  specific  SUFFE  components. 
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4.2.2  Implementation  of  the  New  APFAT  User  Interface 

About  80%  of  the  code  necessary  to  set  up  the  use  Interface  has  been  written  and 
tested.  One  submenu  has  not  been  generated  because  its  component  has  not  yet  been 
implemented. 

There  are  two  application  processing  routines  that  pass  information  between  APFAT 
and  the  u.ser  interface.  Both  routines  are  partially  implemented. 

4.2.3  Modifications  to  APFAT 


Modifications  to  existing  API'A'f  code  turned  out  to  be  minimal:  One  AFPAT  routine 
was  modified  and  one  was  added.  'I'he  new  routine,  SymboLDisplay  proce.s.ses  a 
representative  .set  of  information  from  the  .symbol  table,  but  not  all  information.  All 
information  could  be  displayed  with  simple  additions  to  a  "ca.se"  statement. 


4.2.4  Demonstration  of  APFAT  with  the  New  User  Interface 


A  .omplete  demonstration  of  APF'A'l'  with  its  new  u.ser  interface  is  not  possible  at  this 
writing.  The  applica'ion  executes  and  displays  menus,  submenus.  It  supports  the 
selection  of  files  for  parsing  and  the  selection  of  the  Ada  entity  class  and  the  .symbol 
table  information  to  be  displayed.  'I'he  menu  for  .selecting  identifiers  is  not  complete; 
.symbol  table  information  is  not  currently  displayed  on  the  screen  because  the  text 
display  component  is  not  completed.  Instead  output  is  directed  to  a  file.  In  spite  of 
these  limitations  the  demonstration  gives  a  very  good  feel  for  how  APb'A'f  would  be 
used  through  its  new  user  interface. 


In  addition,  demon.stration  of  the  functionality  of  SUri'F  components  is  possible 
through  the  sub.stantial  test  code  that  was  written,  'I'he  following  te.st  routines  may  be 
used  for  this  purpo.se:  test.a,  te.sL.application_panel.a,  te.sL_commandJtem.a, 
te.sL.commandJist.a,  test-core.a,  test_dialog_panel.a,  te.st_file_selection.a, 
test_menu_com  m  andj  tern .  a,  te.st_resourced_objecl. ,  a ,  tesl_sel  ecti  onj  tern .  a , 

test_.selectionJist.a,  test_text_selection.a,  te.sUoggleJtem.a  tesl_widget_operation.s.a, 
test_x.a  . 


4.3  Comparison  of  Code  Size 

'I'his  section  compares  code  size  and  functionality  of  the  prototype  sample  application, 
API’AT,  with  the  ba.seline  version  of  APb'AT,  V5. 

4,3.1  Metrics  for  APFAT,  Version  5 

Compilation  Unit  Identifier  File  Specification 
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A-:la_Parser 

Ada_Parser 

Ada_Scanner 

Ada_Scanncr 

Adaptalion_l)ala 

Adaptalion_I)ala 

Apfal 

LcxicaLAnalyzer 
LexicaLAnalyzcr 
Parsc_(;ompilalion_U 
Report_Genenalor 
ReporUGenerator 
SymboLDcfinitions 
SymboLManipulations 
SymboLManipuIalions 
SymboLU  1 
SymboLU  I 
User_Inlerrace 
User_Inlerface 
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ada_parscr_.a 

ada_parscr.a 

ada_scanner_.a 

ada_scanner.a 

adaplalion_.a 

adaptation. a 

apfat.a 

Iexical_.a 

lexical. a 

par.se_cu.a 

report.,  a 

report,  a 

.symboLdeL.a 

.symbol_man_.a 

symboLman.a 

symboLui_.a 

.symboLui.a 

u.serjnterrace_.a 

userjnterface.a 


CDRL  01000 


'I’he  original  APl^'A'P  code  (V5)  used  texUo  lor  all  input/output 
and  had  a  command  line  style  interface,  'I'he  size  of  the 
source  code  modules  were  as  follows: 

File:  //node_171 13/locaLuser/r24/APFA'17adaptation_.a 
17  statements  106  lines 

I'ile:  //node_171 13/local_u.ser/r24/APFA'17reporl_.a 
9  statements  99  lines 

File:  //node_171 13/locaLuser/r24/APFA'171exicaL.a 
12  statements  102  lines 

l-'ile:  //nodc_l  71 1 3/locaLuser/ r24/APFA'17 ada_.scanner_.a 

14  statements  151  lines 

File:  // node_J 7 1 1 3/locaLuser/ r24/AP FA'17symboLdcf_.a 
94  statements  256  lines 

l-'ile:  //node_171 13/locaLuser/r24/APFA'17symboLman_.a 

15  statements  109  lines 

File:  //nodo_171 13/local_u.ser/r24/API''A'17symboLui_.a 
15  statements  134  lines 
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File:  //ncKlc^lVl  13/locaLuscr/r24/APl'A’iyada_parser_.a 
2  statements  65  lines 

File:  //nocle_17n3/locaLuser/r24/APF''AT/user_interface_.a 
8  statements  81  lines 

File:  //node_171 13/locaLuser/r24/APF'AT/apral_vdp_.a 
1  statements  204  lines 

File:  //node_171 13/locaLuser/r24/APF'A'r/adaptation.a 
29  statements  194  lines 

File:  //node_171 13/locaLuser/r24/APF’AT/rep()rt.a 
57  statements  230  lines 

File:  //node_171 13/locaLuser/r24/APF‘AT/lexicai.a 
186  statements  669  lines 

File:  //node_l  7 1 13/locaLuser/ r24/APF'A'!7ada_scanncr.a 
79  statements  439  lines 

File:  //node_171 13/locaLuser/r24/APFA'r/symbol_man.a 
442  statements  1393  lines 

File:  //nodc_171 13/locaLuser/r24/APFAT/symboLui.a 
516  statements  1175  lines 

F'ile:  // node_l  7 1 1 3/l()caLuser/ r24/ A PF'AT/ ada_parser.a 
74  statements  282  lines 

File:  //node_l  7 1 1 3/l()caLuser/r24/ APF'AT/ user Jnterface.a 
110  statements  285  lines 

1-ile:  //node_l 71 13/locaLuser/ r24/APFAT/parse_cu. a 
321  statements  686  lines 

F'ile:  //node_171 13/locaLuscr/r24/APF'AT/apral.a 
10  statements  90  lines 

Totals: 

2009  statements  6750  lines 

l-xecutable  (Apollo  1)N3500  (68020,  68881).  SRlO.l,  DomainAda  3.0): 
333455  bytes 
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'I'he  user  interlace  portion  of  APFAT  V5  is  actually  in  several  packages,  but  only  the 
following  packages  were  modified  in  the  adaptation  for  SUI'l'Ii: 

•  userjnterface.a  (file  deleted;  replaced  by  suite_ui.a) 

•  ada  parser.a  (TexUO  calls  eliminated) 

4.3.2  Metrics  for  APFAT  with  SUITE  Interface 

As  mentioned  above,  only  two  of  the  original  APFA'l'  packages  were  modified  or 
removed.  'I'he  following  packages  were  added  to  adapt  APFAT  to  SUITl^: 

•  suite_ui  -  creates  the  SUn'R  user  interface  for  APF'A'l' 


•  symboLdisplay  -  parameterized  output  routines  that  extract  information  in  the 
API’AT  symbol  table  and  format  it  for  output  as  ASCII  text. 

•  parsejile,  selecCsymboIJnfo  -  'I’hese  routines  do  application  processing  as  a 
result  of  user  actions  such  as  selection.  In  general  these  routines  respond  to  user 
input  that  requires  application  processing. 


The  user  interface  portion  of  APF'A'l'  interfaces  to  the  original 
through  only  three  routines: 


code 


of 


APF'AT 


•  Ada_Parser.Parse_Ada_Source_Files  -  Takes  Ada  source  file  name  and  parses 
syntactically  correct  Ada,  building  from  it  a  symbol  table. 


•  SymboLDisplay,Display_Identifier  -  Produces  a  formatted  ASCMl  text  of 
symbt)!  table  information  for  the  specified  Ada  identifier  and  Ada  entity.  'I'he 
kinds  of  symbol  table  information  that  can  be  displayed  include  :  Declares, 
Invoked_By,  Calls,  Arguments,  Handler,  Raises,  References,  RaisecLIn,  Body, 
Used,  Visible,  With_Unit. 


•  .SymboLDisplay.Display_Identifier.s_By_('lass  -  Produces  a  list  of  identifiers  for 
the  given  class  of  Ada  entities.  This  information  is  used  to  con.struct 
Text_Selection  components  that  display  Ada  identifiers. 


The  following  table  summarizes  the  metrics  associated  with  all  new  or  modified 
packages  (Numbers  repre.sent  the  Ada  .statement  count): 


i’ackage 

File 

V5 

Deleted 

New 

userj  liter  face 

userjnterl'ace.a 

118 

118 

0 

ada_parser 

ada_par.ser.a 

74 

10 

5 

.symboLdisplay 

.symboLdisplay.a 

0 

0 

137 
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suile_ui  suite_ui.a  0  0  151 

parsej'ile  parsej'ile.a  0  0  41 

selecUsymboUnlo  selcct_symbolJnl‘o.a  0  0  37 

TOTALS:  192  128  371 


L:xecutable  (Apollo  DN350()  (68020,  68881),  SRlO.l,  DomainAda  3.0): 

1762937  bytes 

Notes:  ('ount  in  number  of  statements.  (\)unts  refer  to  combined  count  of  statements 
in  specification  and  body.  New  statement  count  includes  both  new  and  modified 
statements.  'I'he  package  "symboLdisplay"  represents  new  functionality  that  APl'A'T 
V5  did  not  have.  At  the  time  of  this  writing  the  SUlTlv  user  interface  to  AFFAT  was 
not  completed;  we  expect  the  final  count  to  be  between  250  and  300  statements.  As 
can  be  seen  by  a  comparison  of  the  size  of  executable  image,  the  use  of  SUITF  and 
other  underlying  user  interface  libraries  increase  the  size  by  a  factor  of  about  5.  'I’he 
major  contributor  to  tlie  size  increase  is  llie  size  of  the  underlying  user  interface 
libraries,  in  this  case  Motif  and  X  Windows. 


The  version  of  APFA'l'  that  uses  SUI'Di  is  a  significantly  richer  user  interface  and  is 
much  easier  to  use.  We  also  consider  it  very  significant  that  the  SUri'l.i  version  of 
AFFA'f  permits  modification  and  adaptation  of  the  user  interface  via  "User 
Preferences."  APFAT  V5  has  no  similar  capabilities.  Given  these  facts,  we  consider  it 


impressive  that,  from  the  application  programmer's  point  of  view,  the  increase  in  the 
number  of  statements  is  only  about  250,  or  about  12%  of  the  total  number  of 


statements  in  APl  'A'l'. 


However,  the  statement  count  by  itself  somewhat  underestimates  the  effort  required  by 
the  application  programmer  to  use  the  SUl'l’E  interface,  'fhe  Ada  statements  used  to 
set-up  and  run  the  SUI'l'E  interface  are  somewhat  longer  and  more  complicated  than 
would  be  required  of" only  'lexulO  were  used. 

In  evaluating  the  use  of  SUITli,  several  other  comparisons  would  have  been 
interesting,  but  time  did  not  permit  them  being  made: 

a.  (Compare  the  number  of  additional  .statements  that  would  be  required  to  use 
another  user  interface  toolkit  such  as  Xt/Athena,  Motif,  or  Pre.sentation 
Manager. 

1).  (Compare  the  number  of  language  statement  required  to  use  a 
diaIog/pre.sentation  language  such  as  Motif/UIL  or  Serpent/SLANG. 


Therefore,  our  preliminary  conclusion  regarding  .source  code  size  are  that  the  u.se  of  a 
high  level  user  interface  t(n)lkit  such  as  SUITE  repre.sents  only  a  l()-207o  increase  in 
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code  si‘/c  over  a  user  interlace  that  is  written  using  TexUlO.  The  significant 
advantages  of  using  an  higher  level  toolkit  such  as  SUITE  are;  User  controlled  dialog, 
visual  interface,  keyboard/mouse  equivalence,  consistency  across  device  classes,  and. 
the  ability  to  customize  the  user  interface  through  user  preferences,  (h'or  a  fuller 
discussion  of  these  concepts,  please  refer  to  CDRL  980,  "Programmer's  (luide  for 

suite:". 


4.3.3  Metrics  for  SUITE 

SUri'E  is  comprised  of  about  57  packages  totaling  to  about  14,800  lines  of  code  and 
3100  Ada  statements.  In  addition,  test  ctxle  represents  about  5000  lines  of  code  or 
1700  Ada  statements. 


SUrrii  is  built  on  an  Ada  binding  to  Mofif,  which  in  turn  depends  on  the  "(!" 
implementations  of  Motif  and  Xlib. 

4.4  Comparison  of  Porting  Effort 


After  some  evaluation  and  discussion  with  developers,  it  was  decide  that  a  compari.son 
of  developer  effort  in  pt)rting  applications  would  not  be  meaningful.  A  wide  variety  of 
circumstances  effect  the  amount  of  effort  necessary  to  port  software,  and  in  our 
circumstances  it  was  not  possible  to  hold  any  of  these  variables  constant.  Among  the 
variables  effecting  porting  effort  are:  Stability  of  the  underlying  user  interface 
software,  complexity  of  the  user  interface  ct)ncepts  implemented  by  the  interface,  and 
experience  of  the  programmer. 


To  develop  (design  and  implement)  the  new  user  interface  to  APE’AT,  about  1-2 
weeks  of  effort  were  required.  This  time  could  have  been  reduced  substantially  if  the 
SUrrB  implementation  had  been  complete  and  stable  before  work  began.  There  are 
no  available  figures  for  the  development  of  the  user  interface  for  APEA'l’,  Version  5, 
but  it  was  certainly  a  very  short  time,  since  the  command  line  interface  .style  of  the 
interface  is  extremely  simple. 


5.  IMPLEMENTATION  OF  SUITE 


5.1  Implementation  Goals 

The  Boeing  implementation  of  SUITIv  was  intended  as  a  prototype  and  only  a  sample 
of  the  po.ssible  .set  of  implementations.  Since  X  windows  is  the  mo.st  imporlanl  u.ser 
interface  in  the  marketplace  today,  it  would  be  logical  for  an  initial  implementation  to 
be  on  lop  of  X  windows. 

A  key  aim  of  the  SUITE  implementation  was  to  u.se  an  object-oriented  methodology. 
'I'his  included  the  ideals  of  encapsulation  (all  data  and  operations  on  a  given  object  in 
a  single  place),  implementation  hiding  (unnecessary  details  hidden  from  the  application 
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programmer),  and  inherilance  (operations  and  attributes  of  more  general  classes 
(superclasses)  of  objects  being  available  to  more  specific  subclasses).  Furthermore 
there  was  a  explicit  effort  made  to  use  features  of  the  Ada  language,  rather  that 
language  extensions  or  an  external  library  providing  general  purpose  capabilities 
needed  to  build  components. 

Portability  is  very  important  to  the  concept  of  SUITB.  Major  goals  were  to  minimize 
dependencies  on  the  windowing  system  in  the  application  programmer's  interface  and, 
to  a  lesser  extent,  on  the  compilation  system  in  either  the  application  programmer's 
interface  or  its  implementation. 

Another  goal  of  SUriT-l  was  extensibility,  i.e.  the  ability  for  others  to  define  new  user 
interface  components  for  the  SUITE  object  set.  The  fact  that  geometric  objects  (boxes, 
ovals,  etc.)  were  not  included  in  the  current  version  of  SUnTi  makes  this  particularly 
important. 

5.2  Analysis  of  Implementation  Options 

While  Ada  supports  encapsulation  and  information  hiding,  it  does  not  provide  any 
direct  support  for  inheritance.  Nevertheless,  since  the  requirements  analysis  was  done 
on  object-oriented  lines,  it  was  decided  to  implement  as  clo.se  as  possible  to  them.  'I'he 
most  critical  implementation  option  was  thus  what  mell.od  to  use  for  approximating 
inheritance  in  Ada. 

Six  methods  for  simulating  inheritance  in  Ada  were  considered.  A  comparative 
analysis  of  them  is  shown  in  table  1.  The  six  methods  are: 

1.  Unisys'.  The  method  used  by  Unisys  for  STARS  ta.sk  UR20,  using  subtypes 
and  derived  types  to  simulate  inheritance,  with  two  packages  for  each  object. 
Refer  to  |WAE9()|,  or  to  the  next  section. 

2.  Unisys'  with  derived  typing.  Similar  to  (1),  but  uses  derived  types  and  derived 
operations  at  points  where  Uni.sys  u.ses  subtypes.  Refer  to  the  next  section. 

3.  Perez'.  A  method  developed  by  l.vduardo  Fere/,  rere/,  which  al.so  u.ses  derived 
types  but  only  one  package  for  each  object.  Refer  to  L'ER^Vj. 

4.  Perez'  w/  subtyping  and  renaming.  Similar  to  (3),  but  uses  subtyping  instead  of 
derived  typing  and  renaming  instead  of  implicitly  derived  operations. 

5.  Hide  hierarchy.  Repeating  every  operation  on  a  superclass  in  the  specifications 
of  its  subclasses. 
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6.  Global  (lata  structure.  All  allributcs  for  all  objects  included  in  a  single  data 
structure. 

Three  criteria  are  given  in  the  compari.son: 

1.  Inherit  ability  from  Object  Programmer  Viewpr'nt.  Does  the  person  coding  a 
SUri'l.*^  object  have  to  undertake  any  special  aci,(  s;'  to  simulate  inheritance? 

2.  Inheritability  from  Application  Progran^ype-  V 'a r . .  Does  the  application 
programmer  have  to  undertake  any  .special  aJ'f  '■  .v>  simulate  inheritance? 

3.  Integrity.  Mow  easily  and  how  badly  can  c'dta  l^e  corrupted  or  otherwise 
misused  in  this  method? 


As  shown  in  the  table,  all  six  of  the  methods  make  traiXH.ffs.  Of  these  methods,  it  was 
decided  to  go  with  the  Uni.sys  metlnxl  modifietl  to  u.se  only  derived  types  (method  2). 
'I'his  achieved  a  greater  distinction  between  cla.sves  and  protection  against  their  misu.se 
compared  to  method  (1),  at  the  cost  of  a  greater  amount  of  inct^nvenience  for  the 
application  programmer,  as  di.scus.sed  in  the  following  section.  It  achieved  a  closer 
simulation  of  inheritance  than  the  other  four  methods.  'Hie  most  important  reason  for 
eliminating  the  subtypes  was  that  Unisys  was  implementing  an  Ihtrih.^ic  layer  —  a  .set 
of  operations  shared  by  all  objects  —  while  our  set  of  operations  was  different  for 
each  object  in  order  to  produce  a  better  "fit"  between  objects  and  operations,  in 
Unisys'  case,  making  everything  a  subtype  produced  type  equivalence,  after  which  it 
would  only  be  necessary  to  make  the  Intrinsic  package  visible  to  be  able  to  call  any 
operation.  On  the  other  hand,  without  a  shared  set  of  operations  the  only  way  to  make 
a  supercla.ss  operation  implicitly  available  to  a  subclass  was  through  derived 
operations,  which  are  generated  by  type  -tciivation. 


An  additional  method  for  implementing  inheritance  in  Ada,  C3assic-Ada,  is  di.scu.ssed 


in  section  6.2. 


Another  major  implementation  question  was  the  choice  of  toolkit  to  use  to  interface 
.SUITR  to  X  windows.  Here  the  choice  was  quite  limited  because  few  bindings  from 


Ada  to  X  windows  libraries  were  available. 


The  .STAR.S  Ada  implementation  of  the 


Xt  Intrin.sics  by  Uni.sys  and  SAK!  were  not  available  .soon  enough.  A  .set  of  Ada 
bindings  to  the  O.S17Motif  toolkit  was  available  for  in-house  use  only  from  Boeing 
('ommercial  Airplanes.  Due  to  avaihibility  considerations  the  Ada  bindings  to  Motif 


were  used. 


While  STAR.S  .software  is  public  domain,  the  contractors  were  free  to  u.se  proprietary 
or  in-house  software  in  their  implementatii)...s,  .so  that  the  Motif  bindings  could  be  usetl 
even  though  they  would  not  be  available  to  users  of  .SUl’Ilv.  .Since  the  .SUITl'- 
implcmenlalion  was  considered  a  sample  and  prototype,  it  was  not  crilii^ai  dial  it 
maximi'/.e  its  usability  by  relying  only  on  public  domain  .software. 
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TABU:  1  (iDiTiparison  of  Methods  for  Simulating  Inheritance 


Method 

Inheritability 
from  ob^ject 
programmer 
viewpoint 

Inheritability 
from  application 
programmer 

1  viewpoint 

Integrity 

Unisys' 

1-ull 

Full 

No  protection  against 
violations  of  class  hierarchy 
—  consequences  could  be 
disastrous 

Urisys'  (w/ 
derived  typing 
instead  of 
suhtyping) 

Must  explicitly 
provide  operations 
that  arc  not 
implicitly  derived 

Some  checked  type 

conversions 

necessary 

Allows  vioL;lons  of  class 
hierarchy  it  .-hecked  type- 
conversions  are  done 

Perez' 

Must  explicitly 
provide  operations 
that  arc  not 
implicitly  derived 

Must  explicitly 
convert  objects  to 
superclass  type(s) 
or  use  link 
operation-  to  link 
instances  of  class  & 
superclasses 

hull 

Perez'  w! 
subtyping  & 
renaming 

Must  explicitly 
convert  objects  to 
superclass  typc(s); 
must  provide 
renaming  clauses 
for  all  inherited 
i)perations  & 
attributes 

Mu..v  use  link 
operation  to  link 
instances  of  class  & 
superclasses  wheri 
updating  objects 

I'ull 

Hide  hierarchy 

Must  provide 
subprogr  am  bodies 
for  all  oper'ations 

Full 

Many  subprogram  calls 
requires  pragma  INUNlv 
for  efficiency 
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'rABLl:  1  (!omparison  of  Methods  for  Simulating  Inheritance  [continued] 


Method 

Inheritability 
from  object 
programmer 
viewpoint 

Inheritability 
from  application 
programmer 
viewpoint 

Integrity 

Global  (lata 
structure 

I'ull 

Full 

No  protection  against 
violations  of  class  hierarchy 
(although  data  is  hot 
destroyed);  must  recompile 
entire  system  if  any  attribute 
is  added/changed; 
meaningless  data  is  visible  to 
operations  (stamp  coupling) 

5.3  Description  of  Implementation 
5.3.1  The  Class  Hierarchy 

As  already  mentioned,  SUITE  attempts  to  simulate  inheritance  1)>  a  method  similar  to 
the  one  adopted  by  Unisys  in  task  UR20.  'I’his  method  involves  !wo  sets  of  packages 
Tor  each  object. 

'I’he  first  package  is  the  "public"  spec;  this  is  the  interface  intended  for  use  by  the 
aj'plication  programmer.  Each  class  in  the  public  spec  is  represented  by  a  derived 
type,  which  in  Ada  allows  it  to  inherit  the  operations  defined  for  its  parent  type, 
including  the  operations  that  the  parent  itself  inherited.  (Alas,  constants  and 
exceptions  defined  for  the  class  are  not  inherited,  nor  are  t)perations  in  which  an  object 
of  the  parent  type  is  not  a  parameter,  although  there  were  only  a  few  of  the  latter). 


The  second  package  is  the  "private"  spec,  'i'his  includes  information  that  other  SUITl.^ 
clas.ses  n.’cd  but  the  application  programmer  does  not.  Since  other  classe.s  (packages) 
must  u.se  the  data,  it  cannot  be  hidden  in  the  body  of  the  public  package.  'I'he  primary 
information  i.i  this  package  is  the  record  used  to  contain  the  attribute  data  for  the 
class.  As  slu)wn  in  figure  1,  each  class  record  is  divided  into  two  parts,  an  "inherited" 
part  and  an  "added"  part.  'I'he  inherited  part  is  the  supercla.ss'  data  fields,  .so  that  each 
class  has  all  ()f  the  attributes  of  its  supercla.sses.  The  added  part  contains  the 
information  pertinent  only  for  the  new  class  and  its  subcla.s.ses.’^  To  get  an  attribute  of 


*In  BR22,  SAIC's  class  record  repeals  the  attributes  of  its  supercla.ss  rather 
than  encapsulating  them  as  an  "inherited  part".  'Phis  permits  easier  accc.ss  to 
the  supercla.ss  attributes  at  the  price  of  redundancy. 
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some  distant  superclass,  one  travels  through  the  "inherited"  parts  up  the  superclass  tree 
until  the  proper  "added  part"  becomes  accessible.  Unfortunately,  the  statements  that 
traverse  up  the  inheritance  tree  do  not  indicate  which  class  contains  the  accessed 
attribute,  since  the  access  appears  as: 


<object>.Inherited_Part.Inherited_Fart...Inheriled_Part.Added_Paft 


The  top  of  the  class  hierarchy,  the  class  that  is  the  superclass  of  all  other  classes,  is 
called  Core.  For  the  Core  class  only,  the  data  type  in  the  public  spec  is  a  pointer  to 
the  data  type  in  the  private  spec  (the  (^>re  data  record).  Since  all  other  public  spec 
types  are  derived  from  the  public  C’ore_Type,  that  means  that  all  of  the  public  types 
are  also  pointers  to  the  (lore  data.  In  order  to  access  the  data  for  their  own  classes, 
an  unchecked  conversion  must  be  performed  which  converts  from  a  pointer  at  one 
object  (the  Core  record)  to  a  pointer  at  another  object  (the  class'  own  data  record). 


The  mapping  of  cla.ss  data  into  memory  is  strictly  controlled.  'I’he  inherited  part  is 
always  placed  in  memory  before  the  added  part.  The  inherited  part  may,  in  turn,  have 
its  own  inherited  and  added  parts,  which  must  also  obey  this  rule.  This  structure 
continues  up  to  the  innermost  class  (Core)  which  as  a  result  is  always  is  placed  at  the 
very  lop  of  a  class'  data  structure.  If  the  added  part  contains  components,  then  llu).se 
components  will  have  their  own  inherited  and  added  parts;  care  must  be  taken  to  avoid 
confusing  between  the  core  part  of  an  object  and  the  core  parts  of  its  components. 


The  purpose  of  the  strict  control  over  the  data  structure  is  to  ensure  that  inheritance 
will  work.  An  operation  on  a  class  lakes  an  object  of  a  "public"  data  type,  which  as 
already  mentioned  is  either  (x)re  or  a  derivation  of  it.  If  the  attribute  referenced  is 
part  of  Core,  access  to  the  private  type  is  simple.  If  it  is  in  some  subcla.ss,  then 
unchecked  type  conversions  must  be  performed  to  convert  the  pointer  to  the  private 
(Jorc  into  a  pointer  to  the  private  version  of  whatever  class  contains  the  attribute. 
Without  the  strict  control,  there  would  be  no  guarantee  that  the  proper  data  would  be 
accessible  after  the  type  conversion.  Take  figure  1  as  an  example.  An  Application 
Panel  is  derived  from  a  Resourced  Object,  which  in  turn  is  derived  from  Core.  An 
operation  on  an  Application  Panel  initially  receives  a  pointer  to  Core  and  converts  it 
—  unchecked  —  into  a  pointer  to  Application  Panel:  from  the  point  of  view  of  a 
pointer  to  a  (\)re  object,  the  attributes  of  an  Application  Panel  are  nonexistent;  after 
the  cimversion,  the  Application  Panel  fields  are  made  vi.sible.  But  only  through  the 
strict  control  is  it  a.ssured  that  the  application  panel  fields  are  actually  repre.senled  in 
memory  by  application  panel  data;  olherwi.se  a  compiler  could  rearrange  the  Core  and 
Application  Panel  fields  in  memory  and  create  havoc.  Without  the  repre.sentalion 
specifications,  the  code  would  be  considered  erroneous  by  Ada's  standards. 
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Figure  1  Composition  of  a  SUITE  Component  (Application  Panel) 

The  mapping  of  inheritance  to  Ada  has  some  limitations.  In  particular,  there  are  a 
number  of  operations  in  which  one  object  of  class  X  is  inserted  to  or  retrieved  from 
another  object  of  class  Y.  All  of  these  operations  are  defined  in  the  package- 
corresponding  to  Y.  Now  suppose  we  have  subclasses  for  X  and  Y,  called  X'  and  Y', 
respectively  and  an  operation  f(X,  Y),  which  as  mentioned  above  will  be  placed  in  Y's 
package,  Ada's  type  derivation  mechanism  will  create  a  derived  operation  /(X,  Y'). 
not  f(X',  Y')  which  is  what  we  really  need.  Placing  the  operation  in  X's  package  will 
not  help,  because  then  the  derivation  produces  the  operation  /(X',  Y),  which  is  also 
wrong.  In  this  case,  the  application  programmer  must  perform  an  explicit  (checked) 
type  conversion.  P'or  example,  consider  the  classes  Item  and  List  and  the  operation 

Add  (An_Item;  in  Item;  ,  'IVUJ.st:  in  out  List); 

that  is  defined  in  List's  package.  If  we  have  a  subclass  for  Item  called  Button  and  a 
subcla.ss  for  list  called  Menu,  then  we  will  need  an  operation 

Add  (An_Item:  in  Putton;  To_Li.st:  in  out  Menu); 

but  the  derived  operation  will  actually  have  the  parameter  profile 

Add  (An_Item:  in  Item;  'l\)_Lisl:  in  out  Menu); 

To  invoke  the  derived  operation,  the  programmer  must  convert  his  button  fR)m  type 
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IJulton  lo  type  Ilctn,  using  a  single  checked  type  conversion. 

All  components  and  some  attributes  of  each  object  are  del’ined  internally  as  part  of  the 
object.  Other  attributes,  however,  are  defined  as  resources.  A  re.source,  unlike  an 
internally-defined  attribute,  can  be  set  by  the  u.ser  with  a  file  by  stating  the  name  of  the 
object  (or  its  class  to  affect  all  objects  in  the  class),  the  re.source  name,  and  the  desired 
value.  In  general,  resources  affect  only  the  view  of  an  object  and  not  its  behavior. 
'I'he  decision  of  which  attributes  should  be  resources  and  which  should  not  w'ere  a 
matter  of  balancing  user  tailorability  against  the  ability  of  SUITL  to  control  the 
attribute  to  ensure  proper  behavior. 

The  application  programmer  can  modify  and  query  internally-defined  attributes  with 
operations  defined  in  the  package  of  the  class  containing  the  attribute.  The  t)perations 
on  resources,  t)n  the  other  hand,  are  defined  by  a  single  class  (package), 
Resourced_Object .  It  provides  a  common  .set  of  operations  over  all  resources  using  a 
set  of  generics  that  t)ther  SUI'rii  objects  instantiate  to  define  what  re.sources  they  v/ill 
provide.  'therefore,  while  the  application  programmer  needs  to  refer  to  the 
Re.sourced_()bject  package  to  know  the  .set  of  available  operations  and  their  parameter 
profiles,  he  would  not  actually  be  using  it  directly  (except  ft>r  the  resources  defined  for 
all  classes)  but  rather  the  generic  instantiations  in  the  t)ther  SUITI-1  objects. 

The  Aoa  code  for  a  sample  SUri'I.'.  object  is  shown  in  appendix  A. 


5.3.2  Tlie  Windowing  System  Interface 

'I'he  sample  SUITH  implementation  is  on  top  of  X  windows,  and  specifically  the  X 
toolkit  intrinsics  (Xt).  the  OSF/Motif  widget  set,  and  the  Boeing  (iommercial 
Airplane's  Ada  binding  to  Motif. 

In  several  respects,  Xt  was  inimical  to  t)ur  object-oriented  design  and  to 
object-orientedne.ss  in  Ada. 

We  followed  the  philo.sophy  advocated  by  Grady  Booch  |B0087|  and  I-!d  Berard 
|BI-'R89|  that  objects  be  ignorant  of  the  context  in  which  they  are  used;  for  example, 
an  object  would  have  no  knowledge  of  whether  it  would  be  placed  in  a  .set,  tree,  table, 
etc.  aiul  wouki  not  reference  any  of  those  complex  data  structures.  Xt,  however,  forces 
ct)ntcxtual  knowledge  on  its  users.  'I'his  is  due  to  the  "parent"  parameter  required  when 
creating  an  Xt  object  (widget),  which  specifies  what  t)bject  the  new  widget  is  to  he 
inserted  into  (its  "parent").  F'urthermore,  widgets  must  be  created  in  a  top-down  order 
in  Xt.  i.e.  a  parent  widget  must  be  created  beft)rc  any  child  widgets  can  be  created. 
.SUITIa  has  no  such  restriction  on  the  order  of  creation  of  its  objects.  1‘urthermore,  the 
mapping  of  .some  .SUITF  objects  U)  Motif  widgets  was  context-dependent,  i.e. 
depended  on  what  type  of  object  they  w'ere  placed  into.  I’or  example,  a  SUITF 
.selection  list  could  be  implemented  as  a  Motif  menu  bar  (if  placed  in  an  action  bar),  a 
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pulldown  menu  (if  allached  lo  a  single  menu  choice  within  an  action  bar),  or  a  popup 
menu  (if  attached  to  the  background).  If  this  contextual  information  was  hard-coded 
into  the  parents,  then  extensibility  would  be  reduced.  Resolving  our  methtxiology  with 
Xt's  in  order  to  succe.ssfully  create  widgets  proved  to  be  one  of  the  most  difficult,  if  not 
the  most  difficult,  issue  during  implementation.  After  considering  a  number  of 
methods  which  failed  or  were  fore.seen  to  fail,  we  adopted  a  metluxl  in  which  each 
class  would  have  its  own  widget  creation  pR)cedure.  If  the  parent  widget  were  already 
created,  this  procedure  would  be  invoked  immediately.  Otherwi.se,  it  would  be  invoked 
later,  when  the  object  was  in.serted  into  a  given  parent.  'Ihis  method  involves 
prt>cedure  variables,  another  feature  not  readily  available  in  Ada.  Uni.sy.s'  UR2() 
report  discu.sses  a  complicated  method  of  providing  procedure  variables,  which  time 
did  not  permit  us  to  implement.  Therefore,  we  adopted  a  temporary  restriction  that  all 
objects  could  only  inserted  in  a  top-down  order,  i.e.  no  object  could  be  inserted  into 
a  sectrnd  object  that  was  not  iLself  inserted  into  something  else  (except  ft>r  objects  of 
the  topmost  cla.ss  of  the  parenting  hierarchy.  Application.)  An  intermediate-term 
solution  wt)uld  be  to  hard-code  the  entire  widget  creation  mechanism  within  the 
application,  which  would  allow  objects  to  be  inserted  in  any  order  but  would  reduce 
exten.sibility. 

Xt  alh)ws  an  application  to  respond  to  u.ser  action  (e.g.  selecting  a  push  button  by 
pressing  it)  by  invoking  a  given  pr<Kcdure  each  time  the  user  performs  a  given  action. 
These  procedures  are  referred  to  as  callbacks.  'Ilie  Xt  programmer  can  specify  the 
callback  procedure  corresponding  to  each  object  that  the  u.ser  can  select.  However, 
this  is  another  case  requiring  prtKedure  variables.  If  the  callback  is  parameterless,  it 
can  be  passed  cs  a  variable  by  its  address.  If  it  has  parameters,  some  additional 
means  are  nece.ssary  to  provide  actual  values  for  those  parameters.  'I'his  is  an  even 
more  complicated  pR)cedure  variable  problem  than  the  one  needed  to  create  a  widget, 
since  the  widget  creation  procedures  would  all  have  the  same  number  and  type  of 
parameters  while  callback  procedures  could  have  any  number  of  parameters  of  any 
type.  Uni.sys  does  present  an  even  mt>re  complicated  method  of  simulating  pnxredure 
variables  for  this  case,  w'hich  involves  no  le.ss  than  passing  around  the  entire  calling 
environment.  Rather  than  use  up  the  entire  project  time  lo  implement  it,  we  adopted  a 
method  using  a  .set  of  generic  packages  with  subprogram  parameters,  which  could 
accommodate  callbacks  with  up  lo  three  parameters.  (If  the  application  programmer 
had  a  callback  with  more  than  three  parameters,  he  would  have  lo  bundle  .some  of 
them  into  a  record  and  unbundle  them  when  his  callback  was  invoked.) 

■!‘!;e  callback  procedures  were  another  ca.se  in  which  the  cla.ss  hierarchy  partially 
failed,  since  procedures  in  ne.sled  generic  packages  are  not  derivable  in  Adu.  When 
selling  a  callback  procedure  for  a  subclass  object,  a  type  conversion  again  was 
necessaiy.  .'\iui  if  one  of  the  parameters  lo  the  callback  pnicedurc  was  also  a  generic 
parameter,  then  even  type  ctinver.sion  would  be  insufficient,  as  shown  in  the  following 
example: 

type  Ba.se  is  ... 
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lypc  Derivation  is  new  Base; 

B:  liase; 

D:  Derivation; 
generic 

type  '1'  is  limited  private; 
with  procedure  Callback  (Using:  in  1'); 
package  Operations  is 

procedure  Do_It  ('I'o:  in  T); 

Suppose  you  want  to  call  Do_It  on  both  B  and  D.  You  must  instantiate 
Operations  twice,  once  lor  each  type,  even  though  one  is  a  derivation  of  the  other. 
This  is  caused  by  the  LRM  6.4.1,  which  states  that  if  a  type  conver.sion  is  used  as 
the  actual  parameter  for  Do_lt,  then  the  "type  mark"  of  the  conversion  must  match 
the  type  mark  of  the  i\)rmal  parameter,  i.e.  the  conversion  must  be  from 
Derivation  to  T,  which  would  be  illegal  because  T  is  a  generic  type. 

Some  other  Xt  idio.syncrasies  created  problems  to  try  to  hide  their  effects  from  the 
application  programmer.  One  was  that  no  commands  to  display  or  undisplay 
windows  would  take  effect  on  the  screen  until  "buffer  flushing"  was  done,  by  calling 
either  XuPending  or  XL.Next_Irwent.  In  most  cases,  the  buffer  flushing  could  be 
hidden  away  from  the  application  programmer  during  displaying  or  undisplaying 
commands,  but  there  still  may  be  some  circumstances  where  the  application 
programmer  would  have  to  do  a  "flush"  himself.  (We  accomplished  the  hiding  at 
the  very  end  of  the  project  and  have  not  determined  if  we  covered  all  cases.) 


5.4  Conclusions 

The  application  programmer's  interface  (API)  for  SUl'PE  appears  to  have 
succeeded  in  its  goal  of  hiding  the  underlying  windowing  system  (X’windows)  in  its 
application  programmer's  interface  (public  specs).  While  some  Xt  concepts  have 
been  retained  in  the  API  (e.g.  resources),  steps  have  been  taken  to  allow  such 
concepts  to  be  ported  to  other  windowing  sy.stems.  (With  resources,  a  complete 
interface  has  been  designed  for  resource  management  that  hides  the  Xt  re.source 
manager  from  the  application  programmer.) 

We  have  also  been  successful  in  maximi/ing  extensibility,  at  least  in  concept.  It  is 
possible  that  shorter-term  implementations  would  have  st)me  hard-coding  that 
would  hinder  extensibility. 

SUlTli  was  less  succe.ssful  in  minimi/,ing  dependencies  on  the  Ada  ci)mpilation 
system.  'I'he  use  of  repre.sentation  specs  is  not  a  problem  —  they  actually  enhance 
portability,  for  the  reasi)ns  given  in  .section  5.3.1.  The  main  culprit  was  the  liberal 
use  of  System. Address  and  the  'Address  attribute  in  implementing  procedure 
variables.  This  would  produce  big  headaches  in  trying  to  port  SUIT!'-  to  the  VAX 
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Ada  compiler,  which  does  nol  support  these  constructs. 

SUITl^  has  been  partially  succ  ful  in  implementing  a  class  hierarchy,  using 
derived  operations.  We  were  una  t  to  include  attributes  or  exceptions  in  the  class 
hierarchy,  and  the  previous  section  described  several  cases  in  which  the  application 
programmer  would  have  to  perform  checked  type  conversion.  However,  we  do  not 
know  of  any  method  without  the  use  of  additional  tools  (see  .section  6.2)  that  would 
more  clo.sely  simulate  inheritance  in  Ada  without  permitting  the  class  hierarchy  to 
be  violated  more  easily. 
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6.  RECOMMENDATIONS  FOR  FUTURE  WORK 

6.1  Refine  Foley's  Concept  of  "Selection  Interaction  Task" 

One  of  the  more  difficult  and  rooccurring  problems  of  this  task  was  to  arrive  at  a 
satisfactory  abstraction  for  I'olcy's  concept  of  selection  interaction  task  (Foley  84], 
(('I)RL980|.  'I'his  concept  guided  the  definition  of  the  following  suite  components: 
Selection  item,  selection  list,  command  item,  command  list,  toggle  item,  menu 
command  item,  multi-  and  single-choice  lists,  and  text  selection.  This  part  of  the 
SUITH  class  hierarchy  was  very  unstable,  possibly  reflecting  the  fact  that  the 
correct  abstraction  was  not  being  used. 

Late  in  the  task  we  realized  that  there  might  be  a  substantial  difference  between  the 
selection  of  "actions"  as  opposed  to  the  selection  of  "objects."  Components  adapted 
to  "action"  selection  include  command  item,  command  list,  toggle  items,  and  single 
and  multi-choice  lists.  (Components  adapted  to  "object"  selection  include  text 
selection. 

Additional  analysis  of  the  subject  might  lead  to  a  redefinition  of  classes  and 
operations  adapted  to  each  type  of  selection.  A  subsequent  re-organization  of  the 
SUri'E  cla.ss  hierarchy  would  then  be  required. 

6.2  Explore  Alternative  Implementations  that  use  Language  Extensions  to  Ada 

Classic-Ada,  from  Software  Productivity  Solutions  (SPS),  is  an  Ada  prcproce.s.sor 
intended  to  fully  implement  a  cla.ss  hierarchy  according  to  the  precepts  of 
object-orientedness,-  including  full  inheritance. 

'I'he  use  of  Classic-Ada  somewhat  conflicted  with  our  goal  of  not  using  language 
extensions.  However,  later  in  the  task,  when  implementation  difficulties  were 
apparent,  we  decided  that  it  was  appropriate  to  re-evaluate  the  potential  benefits 
of  using  language  extensions.  We  received  a  temporary. evaluation  copy  of  it  near 
the  end  of  the  R24  schedule.  While  time  has  not  permitted  a  sufficient 
re-implementation  of  SUITF'  to  completely  compare  it  to  our  Ada  implementation, 
we  have  done  enough  to  indicate  that  (.'la.ssic-Ada  might  be  enormously  beneficial, 
its  greatest  impact  in  SUI'l'li  was  for  tho.se  cla.s.ses  that  heavily  used  operations  to 
insert  SUITE  objects  into  other  SUITI'  objects,  which  required  a  large  amount  of 
unchecked  conversions  in  the  .standard  Ada  implementation  but  only  a  single  line  of 
Classic-Ada  code.  One  such  class.  Application  Panel,  required  only  one-sixth  as 
much  code  in  ('la.ssic-Ada  as  conventional  Ada. 

A  critical  question  in  the  ability  to  implement  SUITE  in  Classic-Ada  is  callback 
procedures  (procedure  variable.s).  SPS  claimed  that  the.se  could  be  implemented 
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by  making  the  callback  prt)ccdure  itself  an  object;  we  did  not  gel  the  opportunity  to 
pul  this  claim  to  the  lest. 

The  suggested  work  in  this  area  would  be  to: 

1.  further  implement  the  (!lassic-Ada  version  of  SUI’l'K  enough  at  least  to 
produce  some  graphic  output,  which  at  this  point  mainly  requires  calls  to 
create  Motif  widgets. 

2.  attempt  to  implement  callback  procedures  in  (!lassic-Ada. 

6.3  Demonstrate  Application  Portability 

We  would  prefer  to  demonstrate,  rather  than  to  just  assert,  that  SUITlv  enhances 
the  portability  of  applications  across  a  variety  of  underlying  user  interface  software 
and  classes  of  display  devices.  Currently  our  assertion  of  application  portability  is 
based  only  on  the  abstract  nature  of  the  SUITl.v  user  interface  concepts  and  the 
corresponding  application  programmer's  interface.  A  working  prototype  would 
certainly  be  convincing  everyone  involved,  including  ourselves!  A  very  ct)nvincing 
demonstration  could  be  made  by  porting  SUlTlr^  to  a  character-oriented  display 
device,  such  as  an  ANSI  terminal.  It  is  our  belief  that  the  SUITH  interface  could 
be  adapted  to  such  a  device  without  significant  violence  being  done  to  the  original 
concept.  Such  a  demonstration  would  have  to  be  evaluated  against  the  current 
goals  and  objectives  of  the  S'l’ARS  program,  which  would  appear  to  give  less 
emphasis  to  application  portability  across  a  very  wide  range  of  classes  of  display 
device  and  u.ser  interface  technology. 

6.4  Extend  SUITE  to  Application— specific  Components 

In  the  mi.ssion  statement  for  15R24  fCDRL  980]  it  was  stated:  "SUITB  is  intended 
to  support  a  variety  of  applications  in  the  domain  of  systems  and  software 
engineering.  The  current  scope  of  SUITE  is  limited  to  user  interface  (Ul) 
components  that  are  useful  acro.ss  the  entire  range  of  lhe.se  applications. 
Components  that  are  application-domain  specific  are  beyond  .scope,  but  could  be 
considered  at  a  later  dale,  as  consistent  practice  evolves  in  the  field  and  when 
additional  resources  and  experli.se  are  available." 

There  is  a  need  for  a  wide  variety  of  user  interface  components  to  support 
applications  development  in  the  software  engineering  domain:  Graph,  components 
like  arc  and  nodes  with  subcla.s.ses  implementing  the  semantics  of  different  types  of 
graphs;  pre.senlalion  graphics  components  for  repre.senling  tabular  data,  such  as 
plots,  charts,  and  tables. 
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6.5  Clean— up  SUITE  Implementation 

The  SUl'l'I-!  implemcntalion  would  benefil  from  a  review  and  consolidation  of  code. 
The  following  paragraphs  refer  to  detailed  modifications  to  the  SUI'l'H 
implementation  that  would  improve  robustness,  increase  consistency,  or  simplify 
usage.  'I'he  full  understanding  of  this  li.st  requires  familiarity  with  the  Ada 
implemcntalion  of  SUlTli. 

Add  ln_l{nabled_Slate  as  a  parameter  to  Solcclion_llem.(!reate;  Alternatively, 
specify  that  all  newly  created  object  are  by  default  in  the  enabled  stale. 

Ivvaluale  whether  it  would  be  beneficial  to  implement  menus  using  SF(’  menus. 
The  operation  "set_callback.."  in  menu_command_itcm  subclass  must  be  redefined 
to  lake  a  selection  list  (specifically)  as  an  argument.  'I'he  new  body  would  then 
build  a  menu  tree  from  .scratch. 

Change  DefauluValue  in  package  ID  to  Nul  and  add  an  exception  ID_Is_NuI. 

Each  private  spec  should  have  a  Oeate_Widget  ( Resourced_()bjecL.'rype) 
procedure  which  will  be  invoked  using  a  .system-independent  procedure  variable 
scheme  in  the  long  run  and  by  hard-coding  into  the  global  widget  creation 
procedure  in  the  short  run. 

Destroy  the  old  widget  each  time  you  add  an  object  to  another. 

Replace  use  of  "Object"  in  operations  with  more  definitive  terms. 

Add  a  note  that  all  objects  are  initially  in  uncreated  stale. 

Each  call  to  .set  a  resource  value  w'ill  have  to  produce  a  call  to  Xl_Reali/.e_Widgel 
due  to  the  behavior  of  Xt. 

Add  an  operation  in  .selection  !i.sl  to  add  an  object  to  the  end  of  the  lisl'.^ 

Un-commenl  out  the  record  representation  clau.ses  —  at  the  last  minute! 

Replace  calls  of  Sel_The_(nas.,_Of  (and  Sel_'l'he_lD_Of?)  in  (!reale  with  direct 
record  references. 

Modify  Applicalion_Panel. Destroy  (and  others'?)  to  only  delete  a  widget  if  it  is  not 
NulLWidgel. 

In  Menu_(\)mmand_ltem,  remove  the  conversions  to  Resourced_Objecl. 
leisure  that  all  classes  are  one  linked  word,  with  c  capital  a.s  the  fir.sl  letter  only. 
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(’reale  Interaclor  and  Panel  subclasses, 
children. 


'I’he  Inleractor  subcla.ss  will  have  no 


Rename  package  WidgeLList  to  Resourced_()l)jecL.Lisl. 

Have  a  cleaner  way  of  .stopping  Xl.  Sec  p.  36  of  Xt  fntrin.sics  Manual;  should  call 
XtDestroy  application  context  and  unix  exit.  'I’liis  code  should  probably  be  pul  in 
Application. Destroy. 


Inserting  items  into  a  list  doesn't  give  the  expected  order.  'I'his  is  because  the 
default  insert  procedure  for  composite  widgets  is  to  insert  them  a  the  head  of  the 
list.  'Fhe  behavior  of  the  widget  should  be  modified  by  replacing  the  Motif  insert 
callback  with  one  that  in.scrts  according  to  position. 


Parameters  that  are  ID  or  (’lass  need  only  be  of  type  String,  not  A_Siring,  since  a 
String  parameter  accepts  strings  of  any  length.  (The  SUITlv  bodies  can  do  the 
conversion.) 

Some  classes  of  objects  (e.g.  .selection  lists)  can  validly  either  exist  independently 
(for  selection  lists,  as  a  popup  menu)  or  as  a  component  of  another  object  (for 
selection  lists,  as  a  component  of  a  dialog).  In  the  first  case,  the  object  would  be  a 
secondary  panel;  in  the  second  case,  it  would  not.  Whether  it  is  a  secondary 
panel  or  not  would  not  be  known  until  the  object  was  inserted  into  something  else, 
which  means  that  if  Secondary  Panel  is  a  class,  its  class  would  not  be  known  at 
creation  lime.  Therefore,  "Secondary  Panel"  (independent  displayability)  should 
probably  really  be  an  allribulc  rather  than  a  class. 

Is_Empty  should  probably  be  removed  from  Selection_List,  since  Nul  and 
'rhe_Size_()f  handle  it. 


Routines  to  get/sel  resources  of  different  types  could  be  rewritten  as  generics. 
(WidgeuResources,  Boolean_Rcsources  and  others). 

Increase  length  of  Class  and  ID  types  to  50. 

6.6  Port  the  SUITE  Implementation  to  the  STARS  X/Ada  Interface 

Due  to  availability,  SUITE  was  not  developed  on  lop  of  the  STARS  X/Ada 
interface.  'I’his  would  be  a  natural  and  desirable  transition  when  a  complete 
.STARS  X/Ada  'I'oolkil  (Inlrinsics  and  Widget  Set)  become  available.. 
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A.  vSAMPLL:  CODli  I'OR  A  SUITl-  CLASS 

A.  1  Spec 

with  Component; 
with  ID; 

package  Sample  is 

type  SampleJl'ype  is  new  (A)mponent.(!omponent_'lype; 

—  'I'liis  particular  object  is  clerined  as  a  subclass  oV.  Component  class. 

procedure  Create 
(A_Sample:  out  Samplejlype;  , 

WithJD;  in  ID.lDJl’ype  :=  ID.DefaulcValue; 

Activated:  in  Boolean  ;=  True); 

— I  Lxceptions_Raised> 

— I  ()ut_()r_Memory 
— II  Lxceptions_Rai.sed> 

procedure  Destroy 
(The_Sample:  in  out  SampleJl'ype); 

— |,  Bxception.s_Raised> 

— j  ()bject_13estroyed 
— 11  Exceptions_Rai.sed> 


—  Operatfons  on  the  sample  class'  "activity"  state 
procedure  Activate 
('I’he_Sample:  in  out  SampleJl'ype); 

— ^^1  Exccption.s_Rai,sed> 

— j  ObjecUDestroyed 
— jj  lvxccptions_Raised> 

procedure  Deactivate 
(The_Sample:  in  out  SampleJl'ype); 

— I  l,■!xception.s_Rai.sed> 

— j  ObjecCDestroyed 
— j|  l{xccptions_Raiscd> 

function  l.s_Activatod 

(The_Sample:  SampleJl'ype)  return  Boolean; 

— ^|: !  Jxcep  lions^R  a  i sod  > 

— j  (ObjecLDcstroyed 
— j|  Lxccptions_Raiscd> 
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—  Operations  to  add/change/ retrieve  a  component  that  is  nested 

—  inside  the  sample  object, 
procedure  Set_'rhe_Inner_Window_Or 

('rhe_Sample:  in  out  Sample_Type; 

To:  in  C'omponent.ComponenL.Type); 

—  Any  object  that  is  a  subclass  of  ('omponent  can  be  an  inner  window, 

—  according  to  this  definition. 

function  The_Inner_Window_Of 

(The_Sample:  SampleJIype)  return  Component.Oomponend'ype; 

ObjecL.Not_Created:  exception ; 

Out_Of_Memory:  exception; 

end  Sample; 

The  Sample  class  defined  in  thi.s  package  is  a  subclass  of  the  (Component  cla.ss. 
'I'he  type  derivation  .statement  will  derive  all  operations  in  the  (lomponcnt  package 
on  C!omponenL_Type  types,  as  well  as  those  that  are  inherited  by  (’omponent_Type 
types.  (Actually,  there  are  no  operations  defined  in  the  (\)mponenl  package,  but  it 
does  inherit  operations  from  the  Core  and  Resourced_()bject  packages.  Most 
SUlTli  operations  come  in  sets:  one  or  more  operations  to  change  a  specific 
slate/property  (constructors)  together  with  an  operation  to  query  the  current  state 
value  (selector).  In  this  case,  there  is  an  "activation''  stale  with  two  constructors 
for  it  (Activate  and  Deactivate)  together  with  one  Selector  (Is_Activated).  'I'here  is 
a  pair  of  operations  to  change  the  sample  object's  inner  window.  The  "inner 
window"  properly  is  itself  a  SUrFB  component,  the  "activation"  property  is  not 
another  component  but  rather  an  attribute.  In  the  SUlTll  terminology,  Existence 
is  itself  a  stale,  which  is  changed  by  Create  and  Destroy.  (In  this  case,  there  is  no 
query  operation.)  SUITE  objects  are  all  derived  from  an  access  type 
(('orejlype),  so  all  objects  are  initially  in  a  Destroyed  slate,  that  is  null.  (It  may 
be  curious  to  think  of  an  object  to  be  destroyed  before  it  has  ever  been  created,  but 
from  the  point  of  view  of  the  SUITli  programmer,  there  is  really  no  difference 
between  a  Destroyed  object  and  an  uninitialized  one.)  Passing  an  Destroyed  object 
to  any  operation  except  CTcale  rai.ses  the  exception  Object_Not_(!reated.  Note 
that  a  object  pa.s.sed  to  Destroy  can  later  be  re-(!realed. 

A.2  Private  Spec 

with  Class; 
with  Component; 
with  Resourced_Object_Privale; 
package  Sam ple_Pri vale  is 

type  Added_lnformalion_'rype  is  record 
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Active:  Boolean; 

lts_Inner_Window:  C'omponenl.C.’omponentjrype; 
end  record; 

—  'i'he  type  of  a  component  here  is  its  PUBLIC!  type. 
Added_lnformation_DefauH_Valuc:  constant  Added_jnformation_Type 
:=  (Active  =>  'I'rue, 

It.s_Inner_Window  =>  null 

); 

type  Sample_Record_'l  ype  is  record 

InheritecLPart:  Resourced_C)bject_Private.Resourced_()bjecL.Record_'rype; 
AddecLPart:  Added_Inrormation_'rype; 
end  record; 

—  This  rep  clause  is  to  enforce  the  order  of  the  record  components. 
Added_lnformation_Si'/e:  constant  :=  4<S; 
for  Sampie_Rec<)rd_Type  use  record 
Inherited_Part  at  0  range 

O..Re.sourced_C)bject_Privatc.Rc.sourced_C)bject_rype_Size-l ; 

Added_Part  at  Resourced_()bjcct_Private.  Resourced_()bject_'rype^_Si'/,e 
range  0.,Addcd_Information_Si'/.e-l ; 
end  record; 

DefauluValue:  constant  Sample_RecordJI'ypc 
:=  (InheritecLPart  =>  Resourced_()bject_Private.DefaulLValue, 
AddecLPart  =>  AclclecLInformation_DcfaulLValuc); 

Sample_Record_Si'/.e:  constant  :=  24104; 

— I  De.scription> . 

— I  'I'he  number  of  bits  needed  for  an  object  of  type  Sample^RecorcLType. 

— I  It  is  a  shame  to  have  to  hard-wire  the  size  like  this  rather  than  rely  on  the 
— I  'Size  attribute. 

— I  However,  'Size  is  not  legal  in  record  representation  clauses. 

— j|  De.scription> 


Sample_Cla.ss:  constant  (!la.ss.(.'la.ss_Type 
:=  C.!la.ss.Thc_C!la.s.s_Vcr.sion_Of  ("Sample"); 

— I  Dc.scription> 

— I  'I'his  is  used  by  the  resource  manager  to  determine  the  set  of  resource.^ 
— I  available  for  a  Sample  object. 

— 11  l)e.scnption> 

proced  urc  ( !  rca  tc_The_Wi clget_I  "'or 
(Object:  in  out  Sample_Typc); 
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end  Sample_Privalc; 


'I’hc  "private  spec"  is  where  the  types  for  actually  storing  the  class  data  are  defined. 
In  this  case,  vSample_Record_Type  holds  the  data  for  SampleJlype.  The 
application  programmer  never  needs  to  declare  anything  as  a  Sample_Record_'l'ype 
—  but  other  SUITH.  clas.ses  do.  The  result  is.  that  this  type  declaration  must  be  in 
a  spec  —  but  it  is  better  to  have  it  in  a  different  spec  from  the  one  used  by  the 
application  programmer. 

Note  that  the  data  field  in  Sample_Record_'rype  to  hold  the  lnner_Window 
component  is  of  the  public  (Access)  rather  than  the  private  (Record)  type.  'I’he 
reason  is  that  when  the  body  of  Sample  references  the  lnner_Window  component  of 
a  Sample  object,  it  might  wish  to  invoke  an  operation  on  Inner_Window,  which 
takes  the  public  type  as  parameter. 

As  already  mentioned,  each  private  spec  includes  an  inherited  part  and  an  addetl 
part.  The  inherited  part,  which  represents  the  supercla.ss  information,  is  normally 
the  record  associated  with  its  supcrcla.s.s,  which  in  the  case  of  SampleJlype  is 
C-omponent.  Since  (Component  has  no  data  of  its  own,  the  record  of  Component's 
superclass,  that  is  Resourced_()bject,  is  used. 


Hach  private  spec  should  define  a  default  value  for  its  class.  This  value  is  not  usetl 
by  the  body  of  Sample,  but  it  is  used  by  any  class  that  is  a  subclass  of  Sample  (or 
will  be  later  on  —  extensibility!)  in  the  same  way  that  Sample  u.ses  the  default 
value  of  its  supercla.ss. 


A. 3  Body 


with  (.'la.ss: 

with  SampleJVivate; 

wi th  U nchecked_(  Conversion ; 

with  Unchecked_l)eallocation; 

with  X_ToolkiL.lntrinsics_()Sl-'; 

with  Xm_VVidgel_Set; 

package  body  Sample  is 

subtype  Sample_Recordjrype  is 
Sample_Private.Sample_llecordjrype; 

type  Sample_Record_Acces.sjrype  is  access 
S  a  m  ]7 1  e_Record  Jl'y  pe ; 

—  'rhe.se  type  conversions  allow  access  to  the  Sample_Recordjrype 

—  data  fields. 

function  The_.Sample_Record_Accc.ss_Version_Of  is  new 
U  nchecked_(  Conversion 
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(Source  =>  Samplcjlypc, 

Target  =>  SampIe_RccorcLAcccss_'Iypc 
)■’ 

1  unction  '1  lie_Sample_Version_()l  is  new  Unchecked_(’on version 
(Source  =>  SampIe_RecorcLAcccss_'rype, 

Target  =>  Samplcjlypc 

); 


procetlure  Oeate 
(A_Sample:  out  Samplcjlypc; 

Witli_II):  in  lO.IDJlype  :=  ID.DcfaulLValue; 
■Activated:  in  Boolean  :=  True)  is 

Motir_Sample_Class: 

constant  X_Toolkit_Intrinsics_OSI'.Widget_('lass 
:  =  Xm_W  i  dgeL_S  ct.  Xm_Row_(  !ol  urn  n_W  i  dgtjl_C  .’lass; 

—  Declarations  used  to  access  the  Sample  record  fields 

—  and  convert  it  to  a  SampleJlype. 
The^Samplei_Record_Access: 

Sample_Record_Accessjrype; 


Its_Il):  ID, IDJFype  renames  With_lD; 
begin 

'rhc_Sample_RecorcLAccess  :=  new 

Sample_RecordJl'ype'(Sample_Brivate.Deraull_Value); 

—  Set  the  values  for  the  "ResourcedJl'he.Sample"  part  of  Object. 
'rhe_Sample_Rccord_Acce.ss.Inherited_Part.AddecLFarl 

.  1  ts_W  i  dget_C:  lass 
:=  Motir_Sample_Class; 

'rhe_Sample  :=  'rhe_Sample_Version_()f  (The_Sample_Record_Access); 

—  Initializing  The_Sample  directly  would  have  t)nly  initialized  enough 

—  space  for  the  (lore  part,  because  Samplcjl  ypc  is  a  derivation 

—  of  a  pointer  to  Core. 

—  Set  the  values  for  the  "core"  part  of  ’rhc_Samplc. 

The_Sample.lls_lD  :=  lt.s_lD; 

'rhc_Sample.lt.s_Class  :=  Sample^Privatc.Samplc_(;iass; 
exception 


BR24  I'inal  Report 
1)6  l.V  11000 


.36 


CDRL  01000  The  BOEING  Company 

TASK  BR24 


when  Sloragcjvrror  => 
raise  OuUGlLMemery; 
end  Create; 


procedure  Destroy 

('rhe_Sample:  in  out  SampleJIype)  is 

procedure  D,o_Destruction_()l'  is  new  UncheckedJ)ealUx:ation 
(Object'  =>  Sample^RecordJlype. 

Name  =>  SampIe_Record_Access_'rype); 

'rhe_Sample_Record_Access: 

Sample_RecordjAccess_'rype  := 
The_Sample_Record_Access_Version_Ol‘  (The_Sample); 


begin 

If  'l’he_Sample  =.  Null  then 
raise  Object_NoCCreated; 
else 

DoJ)estruction_Or  ('I'he_Sainp!e_Record_Access) ; 
'riie_Sample  :=  null; 
end  if; 
end  Destroy; 


—  Operations  on  the  sample  class'  "activity"  state 
procedure  Activate 

(The_Sample:  in  out  SampleJIype)  is 

'rhe_Sample_Record_Access: 

Sample_Record_Accessjrype  := 

'rhe_S a m p  1  e_Recor d_ A ccess_ Vcrsion_0 f  (' I’h e_S ample); 

begin 

If 'rhe_Sample  -  Null  then 
raise  ObjecUNoCCreated; 
else 

'rhe_Sample_l^ecord_Access.Added_Fart.Active  :=  True; 
end  if; 

end  Activate; 
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procedure  Deactivate 

(Thc_SampIe:  in  out  Samplcjlype)  is  separate; 
function  Is_Activated 

(The_Sample:  Samplejlype)  return  Boolean  is  separate; 
function  'rhe_lnner_Window_()f 

('rhe_Sample:  Samplejlype)  return  (Component. ('omponenClype  is  separate; 

procedure  Set_'riie_Inner_Window_Of 
('riie_Sample:  in  out  Samplejlype; 

To:  in  (iomponent.Ciomponentjrype)  is  separate; 

end  Sample; 

All  operations  in  SUITl {  packages  receive  as  a  parameter  an  object  of  ({orejfype 
or  a  derivation  of  (lorejlype.  ({orejl’ype  is  a  pointer  to  the  (.‘ore  attributes.  In 
order  to  get  to  any  other  attributes,  including  Sample's  own  attributes,  unchecked 
type  conversion  must  be  performed.  In  the  body  of  Sample,  this  is  'one  by 
invoking  function  The_Sample_Record_Access_Version_Of.  Likewise,  a  call  to  this 
function  must  be  performed  during  Create  so  that  enough  space  is  allocated  for  an 
entire  Sample  record,  not  just  the  C^)re  allribules.* 

All  visible  operations  t)ther  than  Create  should  first  check  to  ensure  that  its  object 
parameter  is  non-null. 

An  operation  that  inserts  a  SUFI'E  component  into  another  SUITI:  component 
(e.g.  SctJI'he_Inner_Window_()f)  is  the  most  difficult  case  to  implement  in 
Motif/Xt,  so  it  is  presented  and  discussed  separately  from  the  rest  of  the  body. . 

A.3.I  A  Component  Insertion  Operation 

with  Core; 

wi  th  Resourced_Object ; 
with  Re.sourced_()bject_Private; 
with  WidgeU.ist; 

.separate  (Sample) 

procedure  Setjrhe_l nner_Wi ndow_()f 
('rhe_Sample:  in  out  Samplejlype; 

'I’o:  in  Component.CiomponenCI’ype)  is 

subtype  lnner_VVindowjrype  is  C^omponent.ComponenCrype; 


*  Because  a  pointer  to  a  Core  object  nni.sl  be  returned  from  the  operation,  the  |)ointcr  to 
tile  .Sample  record  nni.st  be  re-cr>inerled  to  a  pointer  to  Core  liefore  exiting^  the  oper.iiion. 
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'rhc_Inner_Windi)w:  Inncr_Window_Typc  renames  'lb; 

subtype  ResoureetLObjecClypc  is 
Resourced_()bjecl.Resouree<L()bjeeL_rype; 


—  'I’ype  conversions  to  allow  access  to  Inner_  Vindow  record  fields, 
type  Resourced_()bjectJ^ecord_Access_'rype  is 

access  Resourced_Object_Rrivale.ResourcecL()bjecl_Record_'rype; 
function  rhe_Resourced_()bjecL.Vcrsion_()f  is  new  Unchecked_Conversion 
(Source  =>  Component.CbmponenCi’ype, 

'I'arget  =>  Resourced_Obj‘ect_Record_Access_Type 

); 

'rhe_Inner_Window_Rccord_Access: 
Resourced_()bject_Record_Aecess_'rype 
:=  '1  'he_Resourced_Object_Vcrsion_()f  ('riie^l  nner_VVindow) ; 

—  'lype  conversions  to  allow  access  to  the  (bre  subclass  components 

—  of  'riie_SampJc 
'l'he^Sample_Record_Access: 

S  a  m  ple_Rec<)rd_Access„'rype 
:=  'rhe_Sample_RecorcLAccess_Ver.sion_()f  (The_Sample); 


—  'riiere  are  two  Inner_Window  records  referred  to  in  this  subroutine. 

—  'I'he  first  is  the  "workspace"  component  of  'rhe_Sample,  and  the  second 

—  is  the  lnner_Window  parameter,  'lliis  is  the  former  of  the  two. 
'rhe_()bjects_Inner_Wi ndow_l 'icid:  lnncr_Wi ndowjlype 

renames  The_SampleJlecord_Access.Added_Par:.lLs_lnncr_Window; 
The_Inner_Windowj'icld_Record_^ccc.ss; 
Resourced_()bject_RecorcLAcce.ss_'rype; 


function  "="  (x.  y:  X_'roolkit_IiUrinsics_OSr-.Widget)  return  B(K)lean 
ren a mes  XJ lot)! k i L.I ntr insics_OS  1 

iiegin 

if  The_.Sample  =  Null  then 
raise  ()bjecL.Not_Created; 
el.se 

'rhe_.Samplei_Rccord_/\ccc.ss.Addcd_Part.It.s_Inner_Window 
:=  'rhe_l  nner_Window; 

'rhe_Inner_Window_Ficld_Rccord_Acce.ss 

The_Resourced_ObJecL-Vcr.sion_Of 
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('I'hc_Samplc_l^ccortLAccoss.A<JdccLParl.Ils_lnncr_Window); 

—  'I'his  pari  deals  with  creation  of  the  widget  for  The_Inner_Window. 
if  The_Sample_Record_Aceess.lnherilecLFarl.Added_Parl.lls_Resources 
==  X_'l'oolkit_Intrinsics_()Sl-'.NulLWidgel  then 
—  'rhe_Sample's  widget  hasn't  been  created  yet 
—  Save  parent-chiid  information 

if  The_Sample.lls_WidgcL.'rree 
Unoi  dered_Unl)ounded_Managed_'rree.l  imply  then 

—  Oeale  a  new  tree  with  application  panel  as  its  root  and 

—  —  the  workspace's  tree  as  its  subtree 

—  WidgeClVee.Operations.Add_Root 

(To_Make  =>  The_Samplc.lls_WidgeL.'rrce, 
lTom_Ilem  =>  'rhe_Sample, 

AiuLSublree  =>  The_lnner_Window_Record.Widget_rree 

): 

—  else  —  The_Sample's  widget  tree  already  exists; 

—  Add  the  workspace  as  a  new  child 
Widget_List.Add_Objecl 

(ToJ.isl  => 

'rhe_Sample_Record_Access.lnheriled_Parl.Added_l^art.lts_Ohildren, 

Wilh_Value  =>  Resourced_()bjecl_Type('I'lic_Inner_Window) 

); 

The_Inner_Window_I'ield_Record_Access.AddecLPart.lls_Parenl  ;= 
Resourced_Object_'rype((!ore.Core_'rype(The_Sample)); 

—  The_Sample  is  of  Sample  type; 

—  we  need  a  Resourced_()bjecl  type, 
end  if; 

else  —  Thc_Sample's  widget  exists;  Go  ahead  and  create  the  Inner_Window 
widget 


—  In  the  short  term,  this  actually  creates  the  widget 
—  In  the  medium  term,  this  will  do  nothing  and  the  widget  will 

—  be  created  elsewhere. 

—  In  the  long  term,  this  will  invoke  a  subroutine  to  create  the 

—  widget. 

The_Inner_Window_lMeld_Record_Acce.ss.Added_Part.Ils_Re.sources 
:=  X_Toolkil_lntrinsic.s_OSl-’.Xl_Greale_Managed_Widget 
(Name  =>  Il).The_String_Version_Of  (The_Inner_Window.Its_lD), 

Glass  => 

'rhe_lnner_Window_Record_Acce.ss.Added_Parl.ll.s_Widgel_Cla.ss, 

Parent  => 

'rhe_Sample_Record_Access.lnheriled_Parl.Added_Parl.Il.s_Resources 
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); 

end  if;  • 

end  if; 

end  Sel_'riie_Inner_Window_Of; 

Until  procedure  variables  are  supported,  this  procedure  just  invokes  an  operation 
to  create  the  inner  component's  Motif  widget.  This  will  usually  be  through  a  call  of 
Xl_C'reate_Managed_Widget,  unless  Motif  provides  a  convenience  routine  for  the 
desired  widget  class. 

A.4  Private  Body 

with  Sample; 
with  Re.sourced_()bject; 
with  U  nchecked_(  Ion  version ; 
package  body  Sample_Private  is 

procedure  ( ;reato_'rhe_Widget_r*or 
(Object:  in  out  Sample.SampIeJlype)  is 

—  'rhe.se  declarations  allow  access  to  the  Sample  data 

—  fields  of  Object. 

subtype  Samplou.Type  is  Sample,Sample_Type; 
type  Sample_Record_Acce.ss_Type  is  access  Sample_Record_'I'ype; 
functitin  'l'he_Sample_RecorcLAccess_Version_Of  is  new 
Unchecked_(  Conversion 
(Source  =>  Samplejlype, 

Target  =>  .Sample_Record_Access_Type); 

The_Sample_Record_Access: 

S  a  m  p  1  e_Recor  d_A  cce.ss_Ty  pe 
:  =  '  1  'he^S a m p  1  c_Record_ Access_Vcrsi on_Of  (Object) ; 

—  Objects  needed  to  create  the  top-level  (application)  shell 
Some_01ass:  constant  String  :=  "Samplc_clas.s"; 

—  'I'hese  declarations  provide  direct  access  to  Resourced_Object  fields. 
sul)lype  Resourced_Object_Type  is  Resourced_Objcct.Resourccd_ObjccL_Type; 
type  Resourced_Object_Record_Accessjrype  is  access 

l<esourced_ObjecL.Private.Rc.sourccd_ObjecL.Record_Type; 
function  Thc_Resourced_Record_Access_Version_Of  is  new 
Unchecked_(  Conversion 
(Source  =>  Samplejlype, 

Target  =>  Resourced_Object_Record_Accessjrype); 
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'rhc_Resourced_Vcrsioii_Or_()l>ject:  Resc)urcccL()bjccl_'l'ypc  := 
ResourcecLObjecUType  (Object) ; 

—  Holds  value  of  (checked)  type  conversion  from  l-ile.SeleclionJlype. 
The_Sample_Resources: 

Resourced_Object.Resources_'Iype; 

—  Holds  the  Xt  resources  (widget)  data  for  Object. 

—  'I'he  object  that  contains  Object. 

'rhe_Parent:  Resourced_ObjecCrype 
:=  Resourced_Objecl_'rype(The_Parent_Of  (Object)) ; 

—  'rhe_ParenLOf  inherited  from  ResourcecLObject. 

begin  —  (Creatc_'rhe_Widgel_l''or) 

—  Create  the  Sample's  widget. 
rhc_Sample_Re.sources  := 

X_'roolkiL.Intrin.sics_OSF.XL.(>eate_Managed_Widgct 
(Name  =>  ID.The_String_Version_Of 
(Object.Its_ID), 

Cla.ss  =>Sample.The_Widget_(-la.s.s_Of  (Object), 

Parent  =>  Resourced_Object.The_Resource.s_Of  ('I’he  I^ircnt) 

); 

S  et_The_Re.source.s_Of 
(Object,  'I’o  =>  'rhe_Samplc_Resource.s); 

—  Operation  inherited  from  Re.sourced_Object 
end  C>eate_'rhe_Widget_For; 

end  Samplc_Private; 
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